SENDING ELECTRONIC TRANSACTION MESSAGE, DIGITAL SIGNATURE DERIVED 
THEREFROM, AND SENDER IDENTITY INFORMATION IN AADS SYSTEM 



DESCRIPTION 



Cross Reference to Related Applications 

[Para 1] This application is a continuation of and claims the benefit under 35 

U.S.C. Section 1 20 to Wheeler et al., U.S. patent application serial no. 

09/1 89,1 59, titled "Account Authority Digital Signature (AADS) System," filed 

November 9, 1998, now U.S. Patent No. , which application is hereby 

incorporated herein by reference. This application is also related to U.S. 
patent application serial no. 09/860,083 titled "Three Party Account Authority 
Digital Signature (AADS) System," filed May 1 7, 2001 ; U.S. patent application 
serial no. 1 0/01 1 ,496 titled "Account Authority Digital Signature (AADS) 
Accounts," filed December 5, 2001 ; U.S. patent application serial no. 
10/090,091 titled "Sending Electronic Transaction Message, Digital Signature 
Derived Therefrom, And Sender Identity Information In (AADS) System" filed 

March 4, 2002, now U.S. Patent No. ; U.S. patent application serial 

no. 1 0/71 0,972 titled "Account Authority Digital Signature (AADS) System 
Using Encoded Information," filed August 16, 2004, and U.S. patent application 
serial no. 1 0/71 1 ,1 27 titled "Account Authority Digital Signature (AADS) 
System Using Transactional Account Information," filed August 25, 2004. 



Background of the Invention 

[Para 2] The field of the invention relates to digital signatures, and 
particularly, using digital signatures to reliably identify a sender and the 
accuracy of an electronic message without using certification authorities. 

[Para 3] The increase in electronic commerce has increased the focus on 
security of the electronic transactions using this medium of commerce. In the 
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world of computer transactions and electronic contracts, there is no face-to- 
face acknowledgement to identif/ the consumer or other person wishing to 
perform the transaction. As institutions become more reliant on computers, 
they have modified their business infrastructure (i.e., their "business process") 
in an attempt to keep up with electronic commerce. The business process of 
an institution includes the methods used to interact with a customer (e.g., how 
transactions occur, what information is required from the customer, help 
desks to support the customer), the information contained in customer 
accounts, the databases used and how they are modified by the institution, 
and personnel training. 

[Para 4] Institutions and persons desiring to utilize electronic commerce are 
faced with several issues regarding electronic transactions. The first issue is 
whether the person requesting the transaction is who they say they are 
("identification"). And the second issue is whether the requested transaction is 
actually the transaction intended to be requested ("accuracy"). In other words, 
whether the requested transaction has been compromised, either fraudulently 
or through transmission errors, during the course of transmitting and 
receiving the request. 

[Para 5] To address the identity, of the person requesting the transaction, 
current financial business processes bind information in accounts to 
authenticate n on -face-to-face transactions. For example, an account holder's 
mother's maiden name, a personal identification number (PIN), and a social 
security number have all been used and integrated into the current financial 
infrastructure to aid in reliably identifying someone requesting a non-face-to- 
face transaction. 

[Para 6] To address the accuracy of the electronic message being sent and 
the identity of the person sending the electronic message, digital signatures 
are utilized. Digital signatures are used with electronic messages and provide 
a way for the sender of the message to electronically "sign" the message as a 
way of providing proof of the identity of the sender and the accuracy of the 
message. In a digital signature system, a sender digitally "signs" the message 
using a private key (encryption software used to create a digital signature). The 
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receiver validates tPie sender's digital signature by using the sender's public 
key (software used to decrypt the digital signature) sent to the receiver by the 
sender. 

[Para 7] While, digital signatures provide some assurance of accuracy for the 
message and the identity of the sender, they are also subject to security risks. 
These risks include compromised private and public keys or merchant fraud. 
To address the security risks and validate the digital signatures, computer 
technology has developed "certification authorities" to be used in a Certificate 
Authority Digital Signature ("CADS") system. In a CADS system, certification 
authorities are third parties that essentially "vouch" for the validity of a digital 
signature's public key and, hence, the validity of the digital signature. 

[Para 8] However, certification authorities used in the CADS system come 
with inherent risks, such as an expired certification authority and a 
compromised private key, which affect the entire public key infrastructure. In 
addition, the increased reliability provided by certification authorities does not 
easily combine with the business process currently established. 

[Para 9] Therefore, there is a need in the art for a method to increase the 
reliability of electronic transactions while not imposing significant 
modifications on the business processes already in place. 

Summary of the Invention 

[Para 10] The present invention meets the needs described above by 
providing a method of reliably identifying the sender of an electronic message 
and determining the accuracy of an electronic message while utilizing the 
current standard business processes. 

[Para 1 1] The current financial infrastructure can extend existing business 
processes to support high integrity electronic commerce by implementing the 
present invention. One embodiment of the present invention can be 
implemented as the Account Authority Digital Signature (AADS) system. The 
AADS system uses digital signatures along with validation procedures that can 
be implemented within current institutional business processes to identif/a 
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sender of an electronic message and determine tlie accuracy of tlie electronic 
message being sent. 

[Para 1 2] The present invention simplifies its implementation by leveraging 
existing account infrastructures and by operating within existing business 
processes. In addition, the present invention utilizes electronic signatures in 
the business process for increased reliability. Yet, however, the present 
invention does not rely on third parties (i.e., certification authorities) for 
authorization, thereby avoiding any security risks or other systemic risks 
associated with the third parties. And finally, no new databases need to be 
developed to implement the present invention. 

[Para 1 3] Generally described, the identity of a sender of an electronic 
message is validated by using sender validation information along with other 
sender identity information stored at an institution's or person's computer 
system and applying the sender validation information to the encoding 
information received by the computer system. The sender validation 
information is the sender's public key in a digital signature system. 

[Para 1 4] The present invention utilizes the accuracy of electronic encoding, 
e.g., digital signatures, and provides a method to incorporate them into the 
current business processes. An institution records an encoding key (public key) 
and associates it with account information from the sender. This initial 
recording may be performed using any of the validation procedures utilized 
today by a business institution, for example, when the sender is opening a new 
account and must show proof of identity. 

[Para 1 5] After the initial validation of the encoding key, validating future 
electronic transactions occur by including encoding information that can be 
deciphered using the valid encoding key initially stored. To validate an 
electronic transaction, the sender sends the electronic transaction message, 
the encoding information and sender identity information to the person or 
institution from which the sender desires validation. Having received this 
information, the computer system automatically retrieves the encoding key 
stored in the computer system that is associated with the sender identity 
information. The computer system then validates the electronic transaction 
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message by applying the retrieved encoding l<ey to tPie encoding information 
and analyzes the electronic transaction message to validate the identity of the 
sender and the accuracy of the message. 

[Para 16] This validation may be performed in a digital signature system by 
applying a hashing algorithm to the electronic message and comparing the 
results to the results of applying the public key to the digital signature 
received. 

[Para 1 7] The encoding information may be entered into a terminal by means 
of a smart card or by means of another computer system. The encoding 
information, electronic message and sender identity information may be sent 
to the computer system performing the validation via a closed network or via 
an open network, such as the Internet. 

[Para 1 8] These and other advantages of the present invention will be more 
clearly understood and appreciated from a review of the following detailed 
description of the disclosed embodiments and by reference to the appended 
drawings and claims. 

Brief Description of the Drawings 

[Para 1 9] Fig. 1 is a block diagram depicting an exemplary debit card system 
as it exists in the prior art. 

[Para 20] Fig. 2 is a block diagram depicting a Certification Authority Digital 
Signature (CADS) system of the prior art. 

[Para 21] Fig. 3 is a block diagram depicting the digital signature process. 

[Para 22] Fig. 4 is a block diagram depicting the effect of a security breach in 
the existing debit card system. 

[Para 23] Fig. 5 is a block diagram depicting the effect of a security breach in 
the CADS system of Fig. 2. 

[Para 24] Fig. 6 is a block diagram of an exemplary computing environment in 
an embodiment of the present invention. 
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[Para 25] Fig. 7 is a block diagram of the components of an embodiment of 
tPie present invention. 

[Para 26] Fig. 8 is a blocl< diagram depicting an embodiment of tlie present 
invention as it is implemented using a financial institution, a merchant and a 
customer. 

[Para 27] Fig. 9 is a flowchart depicting the steps performed in implementing 
an embodiment of the present invention. 

Detailed Description 

[Para 28] The present invention provides a method for reliably identifying the 
sender of an electronic method and determining the accuracy of an electronic 
message while utilizing current standard business processes. 

[Para 29] Electronic commerce is currently used and implemented in several 
existing systems. The conventional debit card system is one example. The 
debit card system attempts to identify the sender of the electronic message 
(e.g., the message of "Withdraw $200 from my account") while working in the 
current business processes. In other words, it utilizes a PIN as merely another 
validation mechanism. However, the debit card system does not verify the 
accuracy of the message. In addition, because of the security risks, the debit 
card system is not utilized on an open network, such as the Internet, thereby 
limiting it's access to electronic commerce. 

[Para 30] The Certification Authority Digital Signature (CADS) system of Fig. 2 
is another example of a system for implementing electronic commerce. The 
CADS system provides message accuracy and may be used in open networks, 
such as the Internet. However, CADS also has inherent systemic risks and 
requires reliance on third parties to "authorize" the digital signature of the 
sender of the electronic message. In addition, the CADS system is difficult to 
implement using standard business processes utilized today. 

[Para 31] Both the debit card system and the CADS system can have severe 
consequences in the event the security of either system is compromised. The 
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debit card and CADS systems, as well as the security rislcs associated with 
each, are discussed further in Figs. 1-2 and 3-4. 

[Para 32] Turning now to the figures, Fig. 1 is a blocl< diagram depicting a 
conventional debit card system as it exists in the prior art. Typically, a 
customer enters account information and a personal identification number 
(PIN) into a terminal 1 00. The account information is generally stored on 
magnetic tape attached to a card that is given to the customer so that the 
customer may enter it into the terminal 1 00. Upon entering the account 
information and the PIN, the terminal then formats this data and sends it 
across a closed network 1 05 to the main computer 1 1 0 that validates the PIN 
with an associated account that has been entered by the customer. The PIN 
was stored in a field along with other account information in the main 
computer previously. The PIN is typically associated with the customer when 
the account is established but generally not through the network 1 05. Normal 
procedures provide for the customer to validate his/her identity when the 
account is opened or prior to associating a PIN to the customer's account. This 
would verify to the institution that the person establishing the account is who 
they claim to be and increases the reliability that the when the PIN is used, the 
customer assigned the PIN is the person using it. 

[Para 33] Upon validating the PIN with the associated account, the main 
computer 1 1 0 then accepts or rejects the PIN and sends the results back 
through the network 105. The terminal, having received the acceptance or 
rejection, then either continues to process the customer's transaction or 
denies customer access to the account. 

[Para 34] The PIN used in the debit card system is the same for all 
transactions. In other words, no matter what transaction the customer wishes 
to initiate with the main computer, i.e., regardless what message is sent to the 
main computer by way of the terminal, the PIN stays exactly the same. 

[Para 35] The terminal 1 00 used in the debit card system is a basic terminal 
that is used to format the entered information to send to the main computer 
1 1 0. In addition, the terminal 1 00 may perform some function such as 
dispensing cash or other functions specific to the account. However, the 
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terminal 1 00 is generally a dumb terminal only used to facilitate the 
customer's interaction with the main computer 1 10 (i.e., the terminal is not 
typically used for purposes other than to interact with financial institutions). 
The terminal 1 00 communicates with the main computer 1 1 0 by network 1 05. 

[Para 36] The network 1 05 used in the debit card system is typically a closed 
network that is set up specifically for use between the terminal 1 00 and main 
computer 1 1 0. While it is possible that others may break into the network, 
generally, the network 1 05 is not used for other traffic other than messages 
sent between the terminal 1 00 and main computer 1 1 0. 

[Para 37] The main computer 1 1 0 used in the debit card system is generally 
housed at the institution containing the account and contains all the records 
for the institution relative to the account and the PIN. When the account is 
initially set up, all information required to process this transaction as well as 
potentially other transactions within the institution is validated. For security 
reasons, the required information was validated in either face-to-face or in 
some other manner that can validate the customer's identity. Consequently, 
there is a direct validation of the account to the customer when the account is 
established. As stated earlier, the business processes set up in many financial 
institutions today follow this model. These processes include manuals, 
computer databases and records, held desks and personnel training. 

[Para 38] Fig. 2 is a block diagram depicting a Certification Authority Digital 
Signature (CADS) system of the prior art. The CADS system relies on the digital 
signatures and traditional public key infrastructure in issuing certificates that 
are signed by a certification authority (see Fig. 3 regarding a description of 
digital signatures and their usage). A certification authority attests to the 
validity of the public key and sometimes, depending on the authority, checks 
the validity of the private key and the identity information of the entity that the 
certificate is issued to. The sender then sends the certificate, which in this case 
is a digital signature incorporating the sender's digital signature, issued by the 
certification authority; the message; and the sender's public key to the 
receiving party. The intent is that the receiving party will trust the certification 
authority's verification and also will be able to validate the certification 
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authority's digital signature and tPie sender's message using tPie contents of 
tPie information sent by the sender and a public key of the certification 
authority. 

[Para 39] In Fig. 2, the sender 201 creates a digital signature using the 
sender's message 225 (Additional discussion on creation of a digital signature 
is provided below in relation to Fig. 3). Prior to sending the message to the 
receiver 242, it is preferable to validate the sender's message and therefore 
the sender submits the message and the digital signature to a certification 
authority. The intent of the certification authority is to confirm that the 
identified sender is sending the message. Continuing with Fig. 2, the sender 
then has the digital signature "authorized" by a Certification Authority 1 (CAl) 
205. The CA1 has, in advance, identified the public key associated with the 
sender. Therefore, the CAl 205 checks the current digital signature with the 
public key of the sender. Upon a successful check, the CAl 205 then creates a 
digital signature by digitally signing the sender's digital signature. 

[Para 40] An example of a certification authority includes certifying the 
identity of specific banks. However, as there are no rules or laws regarding 
who is a certification authority and who is not and, in some instances, the 
receiver may not "trust" the certification authority. The receiver might be a 
large scale institution that does not trust a certification authority that deals 
with just a few customers or small institutions. Specifically, the receiver may 
not trust that the security is as high as it expects from the certification 
authority. Therefore, the receiver would require a higher-level certification 
authority. In cases like this, the digital signature of the first certification 
authority also needs to be authorized in like manner. This is depicted in Fig. 2 
by CAl sending its digital signature and the sender's digital signature to 
certification authority 2 (CA2) 210. CA2 is, in essence, an authority that 
confirms the identity of other first "level" certification authorities. In the 
example provided, CA2 may confirm the identity of a financial institution 
versus just a bank as in CAl . 

[Para 41 ] This additional certification authority may still not rise to the level of 
security required by the receiver so yet another certification authority may be 
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necessary. This is depicted by CA2 210 creating a digital signature using, i.e. 
by digitally signing, CAI's 205 digital signature and sending CA2's digital 
signature with CATs digital signature on to CA3 21 5. CA3 21 5 could be just 
another higher-level certification authority that checks all institutions. And as 
is apparent, this hierarchy of certification authorities could continue ad 
infinitum. However, at some point, the sender and receiver are satisfied with 
the level of certification authorities and, in Fig. 2, ends with CAS 21 5. CAS's 
digital signature is created by digitally signing CA2's digital signature. The 
sender 201 then attaches the digital signatures 235 to the sender's message 
225 along with the sender's public key 230 into a complete message block 
depicted by 220. The space required for the digital signature may be 
significant in relation to the message. Generally, the classic electronic 
transaction message comprises 80 bytes and the sender's digital signature 
comprises 60 bytes. However, for each certification, it requires another 2,000 
bytes. The size of the message the sender is sending over the network 240 is 
increased substantially by using certification authorities. The sender then 
having combined the message 225, the sender's public key 230, and the 
digital signatures 235, sends this complete packet over the network 240 to the 
receiver 242. 

[Para 42] The receiver now has to validate the sender's message to ensure 
that the authentic sender is sending the message and not a third party using 
the sender's identity. Having received the complete packet 220, the receiver 
242 then begins applying public keys to the digital signatures received in the 
packet. Typically, the receiver will already have the public keys of the 
certification authorities used by the sender. In cases where it is not clear, the 
sender should also send the public keys to the receiver. 

[Para 43] In the instance shown in Fig. 2, because CAS was the final 
certification authority, the receiver then applies CAS's public key to CAS's 
digital signature of the digital signatures 2S5 that were received in the packet 
220. Applying CAS's public key to the CASs digital signature verifies CA2's 
digital signature. Now having CA2's digital signature 245, the receiver applies 
CA2's public key to CA2's digital signature 245 to verify that CAl 's digital 
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signature 250 is unmodified. TPie receiver tiien must apply CAl 's public key to 
CA1 's digital signature to verify that the initial sender's digital signature 255 is 
unmodified. 

[Para 44] While it is shown that this process is performed three times because 
there have been three certification authorities, it will be recognized that this 
process would occur as many times as there are certification authorities used 
for the sender's message. It is clear that this process also adds significant 
overhead processing to the validation of the sender's identity. Particularly with 
the more certification authorities used, the processing and resources required 
purely for the task of validating the sender is increased dramatically. 

[Para 45] Finally arriving at verification 255 of the sender's digital signature, 
the receiver then validates 244 the sender's message 225. The receiver does 
this by using the sender's message 225, the sender's public key 230 that had 
been sent in the initial packet 220, as well as the sender's verified digital 
signature 255 that was created from this process of certification authority 
validation just described. The receiver uses all these components to then 
validate at 244 the sender's digital signature. The receiver may send back the 
results of the validation, or if the validation was successful, act on the message 
sent. 

[Para 46] While the CADS system depicted in Fig. 2 provides some degree of 
reliability confirming the sender's identity, standard business processes are 
not equipped to deal with these kinds of certification authority validation 
procedures. 

[Para 47] Fig. 3 depicts how a message is validated using the digital signature 
process. Initially, the sender creates a message 300 and applies a hashing 
algorithm to the message 300 to create a modified message 305. Because of 
the hashing algorithm, the modified message typically is a much smaller 
version of the actual message itself. 

[Para 48] The modified message 305 that is created using the hashing 
algorithm and the sender's message 300 is not only smaller, but is also unique 
to the message. In other words, as the message changes, the modified 
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message will also change after applying the hashing algorithm. The modified 
message is then encrypted with the sender's private key. 

[Para 49] The process of using a digital signature generally requires a private 
and a public key. These keys are typically obtained from software houses and 
developers that create encryption programs. The private key is used by the 
sender and only by the sender. To maintain the security, as the name implies, 
the private key is intended to be kept private to the sender and not for public 
dissemination. This is the only time in the process, i.e., applying the private 
key to the modified message 305 to create the digital signature 310, where the 
private key is used. 

[Para 50] The creation of the sender's digital signature described above in Fig. 
3 can be performed at the sender's local computer, or in some cases, on a 
smart card. The use of smart cards are well known to those skilled in the art. 
The end result of the sender's process is that the sender has created a digital 
signature. And as stated, this digital signature is message specific, i.e., if any 
letter or any component of the message was changed, this digital signature 
would also change. The digital signature is also specific to the individual 
sender, i.e., the private key encryption method is only for that sender. 

[Para 51] The sender then sends the sender's message with a public key, if 
the receiver does not already have one, and the digital signature to a receiver 
(this "sending" process is not shown). The receiver then takes the received 
message 300' and applies the same hashing algorithm described above for the 
sender to create the modified message 305. Ideally, this should result in a 
modified message 305' that is the same as the modified message 305. The 
only case where the sender's and receiver's modified message is different is if 
the message was corrupted either by the sender after having applied the 
digital signature to it, by transmission errors or someone fraudulently 
intercepting the message and attempting to change its contents. 

[Para 52] Still referring to Fig. 3, next the receiver then takes the received 
digital signature 310' and applies the sender's public key to the digital 
signature. As implied, the public key is available for public use by the sender 
without losing any security of the sender's private key. The receiver then 
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applies the public key to create the decrypted digital signature 31 5. The 
decrypted digital signature 31 5 and the modified message 305' are then 
compared by the receiver. If they both match and are identical, then the 
receiver knows that the message was encrypted with the sender's private key 
and was the same message that has been received. However, because it is not 
known for sure whether the sender's private key has been compromised (e.g., 
stolen), the receiver is still not absolutely sure that the sender identified in the 
message actually is the one who sent it. 

[Para 53] Fig. 4 is a block diagram depicting the effect of a security breach 
(e.g., someone stealing someone's PIN and account info.) in the existing debit 
card system. In this case, the fraudulent customer enters account information 
and a PIN to a terminal 400 and requests a transaction. The same PIN is used 
for all transactions and the PIN typically is an easily remembered non-complex 
set of numbers and/or letters that can be entered by the customer. Once the 
PIN has been compromised for one message, that same PIN can be used for 
other messages that the fraudulent customer wishes to send. 

[Para 54] The terminal 400 having received the account information and PIN 
from the fraudulent customer then, as expected, sends this fraudulent 
information on to the main computer 41 0 through the network 405. The main 
computer 410 is not checking the message against the PIN. It merely receives 
the PIN and checks it against the account that has been stored already in the 
main computer 410. If the fraudulent customer has done his job and has 
stolen the correct PIN, then the transaction will be validated and the 
acceptance will be passed on and the fraudulent customer will have access to 
someone else's account. 

[Para 55] Another area of concern, not depicted in Fig. 4, is when a third party 
steals the customer's PIN by tapping into the network 405. Since no encoding 
or encrypting is performed on the PIN, and since the same PIN is used for all 
messages, once someone has tapped into the network to obtain this 
information, that person is not required to perform any decryption on the 
message and can receive the PIN from the network. Once they have access to 
this PIN, they can then get into the customer's account and send any messages 
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such as checking the account balance and withdrawing funds from the 
account. Having one PIN for all messages facilitates this type of security 
breach. 

[Para 56] Fig. 5 depicts the effect of a security breach, i.e., the stealing of a 
certification authority's private key by a third party, in the existing CADS 
system. When a certification authority's private key is stolen by a third party, 
all messages certified by that authority are suspect because the third party, not 
the certification authority, may generate false messages which appear to be 
authorized by the certification authority. 

[Para 57] In this case, an authentic sender is not attempting to send a 
message 500, and in this example, CA1 has not applied any digital signature 
505 because there is no message. But what has occurred is that there has been 
a security breach in the CA2. For example, CA2's private key has been stolen. 
In general, the effect of having the CA2's private key stolen is that it can then 
mask as any of the CAl s or senders relying on CA2 for certification even 
though they are not attempting to send any messages. In addition, a corrupted 
CA2 private key allows the creation of fictitious CAl s or senders that do not 
exist, yet will appear valid because they are certified by CA2. So, if a 
certification authority can validate that a specific merchant is requesting a 
transaction when that merchant is indeed not requesting a transaction, this 
facilitates the fraudulent use of the electronic commerce system. 

[Para 58] Continuing with Fig. 5, a digital signature 520 of a sender is created 
for a fraudulent message 510 using a fraudulent public key 51 5. The 
fraudulent sender's digital signature 520 then is purportedly digitally signed 
by CAl , and the compromised private key of CA2 is used to digitally sign the 
fraudulent CAl 's digital signature, thereby authorizing CAI's digital signature 
The CAl 's and CA2's digital signatures then are sent to CAS for validation. 
Because the private key of CA2 has been compromised, CA2's digital signature 
is validated by CAB and, consequently, the digital signature and fraudulent 
message block 525 are forwarded on to the receiver 536 over the network 
535. 
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[Para 59] The receiver then receives the fraudulent message 510, the 
fraudulent public key 51 5, and the digital signatures 521 . The receiver then 
runs through the process as described in Fig. 2 to verify the digital signatures. 
The receiver applies CA3's public key to CA3's digital signature 530 and 
verifies 540 that CA2's digital signature is unmodified. It then applies CA2's 
public key to CA2's digital signature and verifies 545 that the fraudulent digital 
signature for CAl is unmodified, even though CAl has not digitally signed this 
message. The receiver then applies CAl 's public key to what appears to be a 
legitimate digital signature of CAl and verifies 550 that a fraudulent digital 
signature of the fraudulent sender is unmodified. This is the case even though 
the sender has not created a message, nor has CAl validated it in any manner. 
The receiver, using the fraudulent digital signature verified at 550 and the 
fraudulent public key 51 5, then validates 537 the sender's purported message. 

[Para 60] The present invention addresses the security needs identified above 
by providing a method of reliably identifying the sender of an electronic 
message and determining the accuracy of an electronic message while utilizing 
the current standard business processes. Below is a description of various 
embodiments of the present invention. 

[Para 61 ] Exemplary Operating Environment 

[Para 62] Fig. 6 and the following discussion are intended to provide a brief, 
general description of a suitable computing environment in which the 
invention may be implemented. While the invention will be described in the 
general context of an application program that runs on an operating system in 
conjunction with a personal computer, those skilled in the art will recognize 
that the invention also may be implemented in combination with other 
program modules. Generally, program modules include routines, programs, 
components, data structures, etc. that perform particular tasks or implement 
particular abstract data types. Moreover, those skilled in the art will appreciate 
that the invention may be practiced with other computer system 
configurations, including hand-held devices, multiprocessor systems, 
microprocessor-based or programmable consumer electronics, 
minicomputers, mainframe computers, and the like. The invention may also be 
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practiced in distributed computing environments wPiere tasl<s are performed 
by remote processing devices that are linked through a communications 
network. In a distributed computing environment, program modules may be 
located in both local and remote memory storage devices. 

[Para 63] With reference to Fig. 6, an exemplary system for implementing the 
invention includes a conventional personal computer 20, including a 
processing unit 21 , a system memory 22, and a system bus 23 that couples 
the system memory to the processing unit 21 . The system memory 22 includes 
read only memory (ROM) 24 and random access memory (RAM) 25. A basic 
input / output system 26 (BIOS), containing the basic routines that help to 
transfer information between elements within the personal computer 20, such 
as during start-up, is stored in ROM 24. The personal computer 20 further 
includes a hard disk drive 27, a magnetic disk drive 28, e.g., to read from or 
write to a removable disk 29, and an optical disk drive 30, e.g., for reading a 
CD-ROM disk 31 or to read from or write to other optical media. The hard disk 
drive 27, magnetic disk drive 28, and optical disk .drive 30 are connected to 
the system bus 23 by a hard disk drive interface 32, a magnetic disk drive 
interface 33, and an optical drive interface 34, respectively. The drives and 
their associated computer-readable media provide nonvolatile storage for the 
personal computer 20. Although the description of computer-readable media 
above refers to a hard disk, a removable magnetic disk and a CD-ROM disk, it 
should be appreciated by those skilled in the art that other types of media 
which are readable by a computer, such as magnetic cassettes, flash memory 
cards, digital video disks, Bernoulli cartridges, and the like, may also be used 
in the exemplary operating environment. 

[Para 64] A number of program modules may be stored in the drives and RAM 
25, including an operating system 35, one or more application programs 36, 
the Account Authority Digital Signature (AADS) module 37, and program data 
38. A user may enter commands and information into the personal computer 
20 through a keyboard 40 and pointing device, such as a mouse 42. Other 
input devices (not shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input devices are often 
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connected to the processing unit 21 through a serial port interface 46 that is 
coupled to the system bus, but may be connected by other interfaces, such as 
a game port or a universal serial bus (USB). A monitor 47 or other type of 
display device is also connected to the system bus 23 via an interface, such as 
a video adapter 48. In addition to the monitor, personal computers typically 
include other peripheral output devices (not shown), such as speakers or 
printers. 

[Para 65] The personal computer 20 may operate in a networked environment 
using logical connections to one or more remote computers, such as a remote 
computer 49. The remote computer 49 may be a server, a router, a peer device 
or other common network node, and typically includes many or all of the 
elements described relative to the personal computer 20, although only a 
memory storage device 50 has been illustrated in Figure 6. The logical 
connections depicted in Figure 6 include a local area network (LAN) 51 and a 
wide area network (WAN) 52. Such networking environments are commonplace 
in offices, enterprise wide computer networks, intranets and the Internet. 

[Para 66] When used in a LAN networking environment, the personal 
computer 20 is connected to the LAN 51 through a network interface 53. When 
used in a WAN networking environment, the personal computer 20 typically 
includes a modem 54 or other means for establishing communications over 
the WAN 52, such as the Internet. The modem 54, which may be internal or 
external, is connected to the system bus 23 via the serial port interface 46. In 
a networked environment, program modules depicted relative to the personal 
computer 20, or portions thereof, may be stored in the remote memory 
storage device. It will be appreciated that the network connections shown are 
exemplary and other means of establishing a communication's link between 
the computers may be used. 

[Para 67] Fig. 7 is a block diagram of the components of the preferred 
embodiment of the present invention. This embodiment of the present 
invention utilizes the paradigm of the digital signatures as described with 
respect to Fig. 3 and merges it into business processes utilized today. 
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[Para 68] Prior to sending a message to the receiver, tPie sender provides tPie 
sender's public l<ey 730 to the receiver 720. The receiver then stores the 
sender's public key 725, which will be used to validate electronic messages 
that will be sent to the receiver. In one embodiment, the sender provides the 
public key to the receiver when the sender initially establishes an account with 
the receiver. It is preferable that the receiver stores the sender's public key 
along with other sender account information such as name, address, PIN, 
mother's maiden name, or other security information that is associated with an 
account. It is also preferable to not send the sender's public key to the receiver 
in the same electronic message that the sender desires to have validated. 

[Para 69] The sender 71 0 then creates a sender's message 700 and attaches 
the digital signature 705. The digital signature was created by the process 
described either in Fig. 3 or by another process as known to those skilled in 
the art. 

[Para 70] The sender sends the sender's message 700 and the sender's digital 
signature 705 to the receiver 720 byway of the network 71 5. The network 71 5 
can either be a closed network as is used in the debit card system, or it can be 
an open network such as the Internet. Because the digital signature is applied, 
if 71 5 is an open network such as the Internet, there is a low probability that 
someone monitoring for traffic and trying to "steal" messages and private 
information will be able decrypt the digital signature of the sender. 

[Para 71] Note that in this embodiment, the sender is not sending the public 
key with the message, and the sender is also not using any certification 
authorities to authorize this message. Also note that because the standard 
business process supports validation criteria, adding another criteria, such as a 
public key, requires minimal modification to the business process. 

[Para 72] The receiver 720 then receives the sender's message 700 and the 
sender's digital signature 705. The receiver 720 then automatically retrieves 
the prestored public key associated with the sender's other account 
information and validates 727 the sender's digital signature using this 
prestored public key. Because a digital signature is being used, no one tapping 
into the network 71 5 will be able to modify the message as it proceeds to the 
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receiver without tlien invalidating the digital signature. If the message is 
modified or corrupted in any manner, the message will fail the validation 
process and the receiver will refuse the request. 

[Para 73] Fig. 8 is a block diagram depicting an embodiment of the present 
invention as it is implemented using a financial institution 825, a merchant 
81 2 and a customer 81 0. The present invention applies in situations where 
security and the sender's identification is required. One embodiment is a 
financial institution that uses standard business processes common in the 
industry today. In this embodiment, the customer 810 generates requests and 
provides account information 800, as well as generates a digital signature 805. 
The customer sends this information through the network 81 5 to the merchant 
81 2. This information can be used under several situations. For example, if a 
customer is purchasing groceries at a supermarket and has a smart card that 
contains his or her private key, or when the customer is using his home 
computer and is trying to purchase a book or other goods over the Internet 
from a merchant. 

[Para 74] The merchant 81 2 then receives the customer's request and account 
information 800 and the customer's digital signature 805. The merchant then 
seeks to have the financial institution authorize the transaction. In other 
words, the merchant wants the financial institution to confirm the identity of 
the customer 81 0 and confirm that there are enough funds in the account to 
make this purchase. In order to have the transaction authorized, the merchant 
sends this information to the network 820 to the financial institution 825 for 
validation. It will be noted that the merchant has not received the private or 
public key from the customer. The merchant has received a digital signature 
from the customer and that digital signature will only be valid for this specific 
request from the customer. If the request is modified in anyway, the digital 
signature will become invalid. This is important because of the high incidence 
of merchant fraud perpetrated by merchants. So, if the merchant cannot 
modify the customer's request in any way without having the digital signature 
becoming invalid, this will provide a significant savings for the financial 
institutions and ultimately the customer as well. 
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[Para 75] The financial institution 825, having received the customer's request 
and account information 800, and the customer's digital signature 805, then 
automatically retrieves the public key 830 that has been previously stored and 
validates 835 the customer's digital signature using the prestored public key 
830. Depending on the purpose for which the present invention is 
implemented, the institution may then act on the customer's request, such as 
to authorize a transaction involving the customer's account. 

[Para 76] When the financial institution is performing an account 
authorization, any of the methods known to those skilled in the art may be 
employed while using the present invention. For example, the financial 
institution may employ a model using an authorization source and a 
transaction process. Under this model, when used with a credit card 
transaction, the authorization source interacts with the merchant to receive the 
customer account information and the transaction request. The transaction 
processor may be used to interact with the credit card issuing association to 
approve the transaction. Methods of account approval are many and are 
considered within the scope of the present invention when the validation of an 
electronic message is required. 

[Para 77] The financial institution 825 then validates the account with the 
digital signature and returns the results of the validation through the network 
820 to the merchant 81 2. The merchant then accepts or rejects the request by 
the customer 81 0, notifying the customer via the network 81 5. The networks 
820 or 81 5 can be open networks such as the Internet, closed networks, or 
one could be an open network while the other is a closed network. 

[Para 78] It should be noted that because the digital signature is encrypted, 
the public key is not being sent (i.e., the public key has been prestored at the 
institution), and no certification authorities are being used, the concern of 
fraudulent tapping into the network to retrieve sensitive customer or sender 
information has been greatly reduced. Further note that the merchant has only 
been a pass through mechanism to confirm the identity of the customer to the 
bank and to verify account information. 
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[Para 79] Fig. 9 is a flow cPiart depicting the steps performed in implementing 
an embodiment of the present invention. Method 900 begins at the start (step 
905) and proceeds to step 910 where public key information is stored in a 
database along with sender identity information about a sender. This may be 
performed in a manner well known, for example, when someone opens up a 
checking account and provides identity information, such as mother's maiden 
name, social security number or other types of information required by 
institutions that require a high level of confidence of the sender's identity. The 
sender identity information may be anything that the institution desires, such 
as account information, sender's name or any other information the institution 
wishes to use to associate the sender's public key to the sender. 

[Para 80] Proceeding to step 920, the sender encrypts a message using the 
sender's private key. This may be performed using the digital signature 
methodology described with respect to Fig. 3, or may be used by other 
encryption methods known to those skilled in the art. After encrypting the 
message, the sender proceeds to step 925 where it sends the encrypted 
message, the original message, and the sender identity information to the 
institution. This may be performed over an open network, such as the Internet, 
where the sender is accessing via a computer, or it may be over a closed 
network where the sender is sending the encrypted message by way of a smart 
card at a terminal. 

[Para 81] [0080]Proceeding to step 930, the institution receives the encrypted 
message, the original message, and sender identity information and 
automatically searches the database, using the sender identity information, to 
find the sender's public key. The public key that is associated with the sender 
identity information is then retrieved from the database. At step 930, the 
institution decrypts the encrypted message using the retrieved public key that 
was associated with the sender identity information provided in step 91 0. 

[Para 82] Proceeding to step 940, the institution then validates the decrypted 
message with the original message sent. In one embodiment, the validation is 
performed using the digital signature validation paradigm previously 
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described. After performing the validation, metliod 900 proceeds to step 945 
and stops. 

[Para 83] This validation process provides two purposes: (1 ) it determines 
whether the sender is the originator of the message because it is based on 
validation information provided by the sender to the institution; and (2) it 
validates the accuracy of the received message by detecting any changes to the 
message that was sent. 

[Para 84] The present invention has been described in relation to particular 
embodiments which are intended in all respects to be illustrative rather than 
restrictive. Alternative embodiments will become apparent to those skilled in 
the art to which the present invention pertains without departing from its spirit 
and scope. Accordingly, the scope of the present invention is defined by the 
appended claims rather than the foregoing description. 
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